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[57] 


ABSTRACT 


A computer network having multiple, dissimilar network 
devices includes a system for implementing high-level, 
network policies. The high-level policies, which are gener- 
ally device-independent, are translated by one or more 
policy servers into a set of rules that can be put into effect 
by specific network devices. Preferably, a network admin- 
istrator selects an overall traffic template for a given domain 
and may assign various applications and/or users to the 
corresponding traffic types of the template. Location- 
specific pohcies may also be established by the network 
administrator. The policy server translates the high-level 
policies inherent in tfie selected traflBc template and location- 
specific policies into a set of rules, which may include one 
or more access control lists, and may combine several 
related rules into a single transaction. Intermediate network 
devices, which may have one or more roles assigned to their 
interfaces, are configured to request traffic management 
information from the policy server which replies with a 
particular set of transactions and rules. The rules, which may 
correspond to the particular roles assigned to the interfaces, 
are then utilized by the intermediate devices to configure 
their particular services and traffic management mecha- 
nisms. Other rules are utilized by the intermediate devices to 
classify packets with a particular priority and/or service 
value and to treat classified packets in a particular manner so 
as to realize the selected high-level policies within the 
domain. 

18 Clahns, 9 Drawing Sheets 
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METHOD AND APPARATUS FOR DEFINING 
AND IMPLEMENTING HIGH-LEVEL 
QUALITY OF SERVICE POLICIES IN 
COMPUTER NETWORKS 

HELD OF THE INVENTION 

The present invention relates generally to computer 
networks, and more specifically, to a method and apparatus 
for applying high-level, quality of service policies at dis- 
similar computer network devices. 

BACKGROUND OF THE INVENTION 

A computer network typically comprises a plurality of 
interconnected entities that transmit (i.e., "source") or 
receive (i.e., "sink") data frames. A common type of com- 
puter network is a local area network ("LAN") which 
typically refers to a privately owned network within a single 
building or campus. LANs employ a data communication 
protocol (LAN standard), such as Ethernet, FDDI or token 
ring, that defines the functions performed by the data hnk 
and physical layers of a communications architecture (i.e., a 
protocol stack), such as the Open Systems Interconnection 
(OSI) Reference Model. In many instances, multiple LANs 
may be interconnected by point-to-point links, microwave 
transceivers, satellite hook-ups, etc. to form a wide area 
network ("WAN"), metropolitan area network ("MAN") or 
intranet. These LANs and/or WANs, moreover, may be 
coupled through one or more gateways to the Intemet. 

One or more intermediate devices are often used to couple 
LANs together and allow the corresponding entities to 
exchange information. For example, a bridge may be used to 
provide a "bridging" function between two or more LANs. 
Alternatively, a switch may be utilized to provide a "switch- 
ing" function for transferring information, such as data 
frames, among entities of a computer network. Typically, the 
switch is a computer having a plurality of ports that couple 
the switch to several LANs and to other switches. The 
switching function includes receiving data frames at a 
source port and transferring them to at least one destination 
port for receipt by another entity. 

Switches may operate at various levels of the communi- 
cation protocol stack. For example, a switch may operate at 
layer 2 which, in the OSI Reference Model, is called the data 
link layer and includes the Logical Link Control (LLC) and 
Media Access Control (MAC) sub-layers. Data frames at the 
data link layer typically include a header containing the 
MAC address of the entity sourcing the message, referred to 
as the source address, and the MAC address of the entity to 
whom the message is being sent, referred to as the destina- 
tion address. To perform the switching function, layer 2 
switches examine the MAC destination address of each data 
frame received on a source port. The frame is then switched 
onto the destination port(s) associated with that MAC des- 
tination address. 

Other devices, commonly referred to as routers, may 
operate at higher communication layers, such as layer 3 of 
the OSI Reference Model, which in TCP/IP networks cor- 
responds to the Intemet Protocol (IP) layer. Data firames at 
the IP layer also include a header which contains an IP 
source address and an IP destination address. Routers or 
layer 3 switches may re-assemble or convert received data 
frames from one LAN standard (e.g., Ethernet) to another 
(e.g. token ring). Thus, layer 3 devices are often used to 
interconnect dissimilar subnetworks. 

User Priority 

FIG. 1 is a block diagram of a data link (e.g., Ethemet) 
frame 100 which includes a MAC header 102 and a data 
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field 104. MAC header 102 includes a MAC destination 
address (MAC DA) field 106 and a MAC source address 
(MAC SA) field 108. Recently, a proposal was made to 
insert a new field after the MAC SA field 108. More 
specifically, the Institute of Electrical and Electronics Engi- 
neers (IEEE) is working on a standard, the IEEE 802,10 
draft standard, for adding information to MAC headers. In 
particular, the 802. IQ standard defines a tag header 110 
which is inserted immediately following the MAC DA and 
MAC SA fields 106. 108. 

The tag header 110 comprises a plurality of sub-fields, 
including a Tag Protocol Identifier (TPID) field 112, a 
userjriority field 114, a Canonical Format Indicator (CFI) 
field 116 and a Virtual Local Area Network Identifier 
(VLAN ID) field 120. The user_priority field 114 permits 
network devices to select a desired priority of data link 
frames. In particular, in an IEEE appendix, referred to as the 
802. Ip standard, the IEEE has defined eight possible values 
of user priority (0-7), each of which is associated with a 
specific traflSc type. The proposed user priority values and 
corresponding traflSc types specified in the 802. Ip standard 
are as follows. 


User Prioiily 



\^!uc 

TYaffic Type 

Description 

3 

Background 

bulk transfers 

2 

Sparc/Reserved 

n/a 

0 

Best Effort 

current LAN trafiSc 

3 

Excellent Effort 

best effort type of services 
(e.g., for an organization's 
most important customers) 

4 

Controlled Load 

important business 
applications 

5 

Yidso (<300 milliseconds 
latency and jitter) 

minimum jitter 

6 

\bice (<10 milliseconds 

one-way transmission through 


latency and jitter) 

the LAN 

7 

Network Control 

characterized by a "must get 
there" requirement to maintain 
and support the network 
infrastructure 


An intermediate device may provide a plurality of trans- 
mission priority queues per port and, pursuant to the 802, Ip 
standard, may assign frames to different queues of a desti- 
nation port on the basis of the frame's user priority value. 
For example, fi-ames with a user priority of "0" are placed 
in the "0" level priority queue (e.g., non-expedited traflSc), 
whereas frames with a user priority of "3" are placed in the 
level "3" priority queue. Furthermore, frames stored in a 
higher level queue (e.g., level 3/excellent effort) are prefer- 
ably forwarded before frames stored in a lower level queue 
(e.g., level 1/background). This is commonly refenred to as 
Priority Queuing. Thus, by setting the contents of the 
user_priority field 114 to a particular value, a device may 
affect the speed with which the corresponding frames 
traverse the network. 

If a particular intermediate device has less than eight 
priority queues per port, several of the IEEE trafiGc types 
may be combined. For example, if only three queues are 
present, then queue 1 may accommodate best effort, excel- 
lent effort and background traffic types, queue 2 may accom- 
modate controlled load and video traffic types and queue 3 
may accommodate voice and network control traffic types. 
The IEEE 802. Ip standard also recognizes that intermediate 
devices may regenerate the user priority value of a received 
frame. That is, an intermediate device may forward the 
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frame with a different user priority value (still within the predefined criteria. When a packet is received by such a 

range of 0-7) than the one it had when the frame was device, it is tested against each of the criteria statements of 

received. Nevertheless, the standard recommends leaving the corresponding list. If a match is found, the packet is 

the user priority value un-changed. cither forwarded or dropped as provided by the list. The 
Type of Service 5 criteria may be source address, destination address, or 

HG. 2 is a block diagram of a portion of an Internet «PP"-layer applicaUon based on their TCP/UDP port num- 

Protocol Version 4 aPv4) compliant IP header 200. Tht IP ^ers. For maniple, an access hst may allow e-maU to be 

header 200 is also made up of a pluraUty of fields, including fp'^'^ded but cause dl Jehiet traffic to be dropped. Acce^ 

c ' /T c\R ijini * ♦ r ^/T-rT\«-ij usts mav be estabushed for both mbound and outbound 

a type_of„service (ToS) field 202, a time to live (TTL) field j . i ^j- 

2M. an IP source address (IP SA) field 206 and an IP ^affic and are most commonly configtrred at layer 3 devices 

destinaUon address (IP DA) field 208. Tbc ToS field 202 is ^P^^^^, f "'."f''" °V S^'^'^^V^ °' 

intended to allow an entity to specify the particular service ^"^"^^^^ ^ P"'''"^ ^«=^"'y '° 

it wants, such as high reliability, fast delivery, accurate Congestion Control 

delivery, etc., and comprises a number of sub-fields. The Congestion typically refers to the presence of too many 

sub-fields include a three bit IP precedence (IPP) field 210, packets in a subnet or a portion of a network, thereby 

three one bit flags (D, T and R) 212, 214 and 216 and two degrading the network's performance. Congestion occurs 

unused bits 218. By setting the various flags, a host may when the network devices are unable to keep up with an 

indicate which overall service it cares most about (i.e., increase in trafiSc. As described above, a layer 3 device 

Delay, Throughput and Reliability). Although the ToS field typically has one or more priority queues associated with 

202 was intended to allow layer 3 devices to choose between each interface. As packets are received, they are added to the 

different links (e.g., a satellite link with high throughput or appropriate priority queue for forwarding. Nevertheless, if 

a leased line with low delay) depending on the service being packets are added to the queue faster than they can be 

requested, in practice, most layer 3 devices ignore the forwarded, the queue will eventually be filled forcing the 

contents of the ToS field 202 altogether. Instead, protocols at device to drop any additional packets for that queue. The 

the transport layer (layer 4) and higher typically negotiate dropping of packets when a queue is full is referred to as tail 

and implement an acceptable level of service. Version 6 of drop. The point at which tail drop occurs, moreover, may be 

the Internet Protocol (IPv6) similarly defines a traflic class configured to something less than the capacity of the queue, 

field, which is also intended to be used for defining the type Since tail dropping discards every packet over the queue 

of service to be applied to the corresponding packet. Umit, it often affects multiple upper layer applications simul- 

Recently, a working group of the Internet Engineering taneously. Furthermore, many upper layer applications, such 

Task Force (IETF), which is an independent standards as TCP, re-send messages if no acknowledgments are 

organization, has proposed replacing the ToS field 202 with received. Thus, the presence of tail dropping can cause 

a one octet differentiated services (DS) field 220, The first global synchronization among upper layer applications, sig- 

six bits of the DS field specify a differentiated services nificantly exacerbating the congestion problem. To avoid 

codepoint while the last two bits are unused. Layer 3 devices global synchronization, some layer 3 devices use Random 

that are DS compliant apply a particular per-hop forwarding Early Detection (RED), which selectively drops packets 

behavior to packets based on the contents of their DS fields when congestion first begins to appear. By dropping some 

220. Examples of per-hop forwarding behaviors include packets early before the priority queue is fiiU, RED avoids 
expedited forwarding and assured forwarding. The DS field ^ dropping large numbers of packets all at once. In particular, 

220 is typically loaded by DS compliant intermediate when a calculated average queue depth exceeds a minimum 

devices located at the border of a DS domain, which is a set threshold, the device begins dropping packets. The rate at 

of DS compliant intermediate devices under common net- which packets are dropped increases Linearly as a function of 

work administration. Thereafter, interior DS compliant a probability constant. When a maximum threshold is 

devices along the path simply apply the assigned forwarding reached, all additional packets are dropped. An extension to 

behavior to the packet. RED is Weighted Random Early Detection (WRED), which 

Although layer 3 devices, like their layer 2 counterparts, applies different thresholds and probability constants to 

typically have multiple priority queues per port or interface, packets associated with different traffic flows. Thus, WRED 

layer 3 devices often apply scheduling patterns that are more allows standard traffic to be dropped more frequently than 
sophisticated than simple Priority Queuing. For example, 50 premium traffic during periods of congestion, 

some layer 3 devices forward one packet from each queue in Service Level Agreements 

a round robin fashion. Another approach, referred to as fair Xo interconnect dispersed computer networks, many oiga- 

queuing, simulates a byte-by-byte round robin to avoid nizations rely on the infrastructure and facilities of service 

allocating more bandwidth to sources who transmit large providers. For example, an organization may lease a number 
packets than to those who only send small packets. Another 55 of Tl lines to interconnect various LANs. These organiza- 

approach, called Weighted Fair Queuing (WFQ), allocates tions typically enter into service level agreements with the 

more bandwidth to specific traffic flows or sources, such as service providers, which include one or more traffic speci- 

file servers, based on source IP address. Transmission Con- fiers. These traffic specifiers may place limits on the amount 

trol Protocol (TCP) or User Datagram Protocol (UDP) of resources that the subscribing organization will consume 
source port, etc. 60 for a given charge. For example, a user may agree not to 

Some networking software, including the Internetwork send traffic that exceeds a certain bandwidth (e.g., 1 Mb/s). 

Operating System (lOS) from Cisco Systems, Inc., support Traffic entering the service provider's network is monitored 

the creation access control lists or filters, which are typicaUy (i,e,, "policed") to ensure that it complies with the relevant 

used to prevent certain traffic from entering or exiting a traffic specifiers and is thus "in-profile". Traffic that exceeds 
network. In particular, certain layer 3 devices utilize access 65 a traffic specifier (i.e., traffic that is "out-of-profile") may be 

lists to control whether routed packets should be forwarded dealt with in a number of ways. For example, the exceeding 

or filtered (i.e,, dropped) by the device based on certain traffic may be dropped or shaped. With shaping, the out-of- 
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profile trafiBc is temporarily stored until the demand drops one or more policy servers into a set of rules that can be 

below the threshold. Another option is to mark the traffic as applied by specific network devices. In particular, a network 

exceeding the traffic specifier, but nonetheless allow it to administrator first selects an overall traffic template for a 

proceed through the network. If there is congestion, an given network domain and may assign various applications 
intermediate device may drop this "marked" or down graded 5 and/or users to the corresponding traffic types of the tem- 

traffic first in an effort to relieve the congestion. Another plate. The network administrator may also select or define 

option is to change the accounting actions for this out-of- one or more location-specific policies. As mformation is 

profile traffic (i.e., charge the user a higher rate). added to the template and the location-specific policies are 

Allocation of Network Resources defined one or more corresponding data structures may be 
^ , 1 . 1 J -in up-dated. The selected traffic template, location-speafic 

As shown, computer networks mclude numerous services . j j * * * • j ♦ 

j *^. , »- , policies and data structures are received at one or more 

and resources for use in movmg traffic around the network. -.u- *u . i ^ • c u v 

_ 1 j.iv. , 1 L 1- .T-.i. * policy servers within the network domam. Each pohcy 

For example, d^eient network hnte^ such ^^/^ high-level policies inherent in the 

Asynchronous Transfer Mode (AIM) channels, nehvork ^j^^^^ ^^^^ template, location-specific policies and data 

tunnels, satelute hnks, etc., offer unique speed and band- * ^ • * * ^ i j u- i i * j 
."^ * ..... „ • 1 • . J- . J • I 15 structures into a set of rules and may combine several related 

width capabilities. Particular intermediate devices also , „ ^. . *„„^„„*'„„ tt«^„ ;«t<.„«^ 

. , , *^ , . r rules mto a smele transaction. Upon mitializaUon, interme- 

include specific resources or services, such as number or j-^j- — t 

. . ^, rj-rc . diate devices request traffic management mformation from 

priority queues, filter settings, availabihty of different queue more policy serves. The policy server replies 

selection strategies, congestion control algonthms^ etc. ^ particular seToffransactions and rulesthatare utihzed 

Nonetheless, these types of resources or services are highly the intermediate devices for traffic management deci- 

device-specific. That is, most computer networks include * n *• «u i Tu ♦ i 

* , . ' - , j./r . sions. By propagating these rules across the network 
intermediate devices manufactured by many different , • i_ r j- • -i ■ * j- * j * 

J 1 • j-rr . i_ J 1 jr. domam, each of the dissimilar intermediate devices can 

vendors, employing different hardware platforms and soft- c -* j- * «= _ * „ 

* V . 1 - J, • r i_ configure its corresponding traffic management components 
ware solutions. Even intermediate devices from the same j l - * 7- u * i 

- , . j-rc • J .1. and mechanisms to operate in such a manner as to imple- 

vendor may be runnmg different software versions and thus .*l u- ui i r - i ♦ j u «u ♦ i aZ- 

• J IV r« , 9« ment the high-level pohcies selected by the network admm- 

provide different functionality. Thus, there is no consistency istrator ^ 

of resources at each of the intermediate devices and, * • , • 
therefore, it is generaUy not possible to simply select a single ^ore specificaUy, a particular differenUat^ service (DS) 
set of parameters for use in configuring all of them. codepomt is preferably assigned to each traffic type of the 
» . ^ ^ t selected traffic template, based on the overall pnonty estab- 

In addition, the allocation of network resources and ^^^^^ ^ administrator. TTie DS codepoint 

services is becoming an important issue to network admm- .^^^^^ ,,,3t^,„t of the corresponding 

istrators and service providers as greater demands are bemg ^^^^ j,^,^^,^^ of classification 

placed on their networks. Nonethele^ at the present time. ^^^^ generated by the policy server instructing 

there are few if any techniques available for applymg traffic intermediate devices to associate particular traffic types with 

management pohcies across a network. Instead the aUoca- ^^j^ corresponding DS codepoints. For example, the clas- 

tion of network resources and services is typically achieved ^^^^^^ intermediate devices to load a 

by manually configuring the interfaces of each intermediate articular DS codepoint within the DS field of received 

device. For example, to the extent there are parameters ^^^^^^ p^^^^^, ^^ssages, depending on the type of IP 

associated with a particular queuing strategy avaUab e at a ^ ^ associated with a stock exchange 
given mtermediate device (e^g., queue length for tail drop ^ ,i^,tioi,). Devices that are not DS-compliant may receive 

and mmmium. maxmium and mark probabUity for RED). classification rules instructing them to load a given value 

these parameters must be set device-by-device by the net- ^^^^ type_of_service or user_priority fields of received 

work admimstrator. Tlis k a time consuming and error ^^^^js or frames. The classification rules, which may 

prone solution. In addition, there are few if any tools j^^,^^^ ^^^^ ^^^^^ preferably 

currently available to network admimstrators suggestmg pj^vided to all intermediate devices located at the boundary 

how various network resources and services might be coher- ^^^^^ ^^^^^ ^ ^^^^^ j^^^ associated with 

ently allocated in order to implement any general pohcies corresponding DS codepoint as soon as it enters the 

Accordingly, the abihty to aUocate network services and ^^^^^ Classification niles may also be used to associate 

resources to implement network-wide quahty of service q^^^jj service (QoS) labels to specific traffic types. QoS 

pohcies B difficult and tune-consummg. ^^^^^^ intermediate devices in making traffic 

SUMMARY OF THE INVENTION management decisions, although, unlike the DS codepoints 

which are generally present in messages traveling the 

It is an object of the present invention to provide a method network, QoS labels are only associated with messages 

and apparatus for applying high-level quality of service ^1,^^ they remain within the intermediate device, Classifi- 

policies, cation rules may also be used to assign DS codepoints and/or 

It is a further object of the present invention to provide a QoS labels to data traffic generated within the network 

method and apparatus for translating high-level policies into domain from un-trusted sources. 

a form that may be understood and applied by numerous implement specific traffic management policies or 

dissimilar network devices. treatments, the policy server also defines a plurality of 

It is a further object of the present invention to classify eo behavioral rules that basically instruct the intermediate 

data traffic upon its entering a given network domain and to devices how to manage data traffic that has been associated 

manage that traffic based on its classification. with a particular DS codepoint, QoS label, type of service 

Briefly, the invention relates to a method and apparatus and/or user priority value. For example, a behavioral rule 

for implementing high-level policies within a computer may instruct the intermediate devices to place all messages 
network having multiple, dissimilar network devices. The 65 associated with a particular DS codepoint (e.g., data frames 

high-level policies, which are generally device-independent, from a stock exchange application or from a corporate 

are selected by a network administrator and translated by executive) in a high priority queue. To implement traffic 
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management policies that are independent of DS codepoints switch 308 and routers 316-318, by links 324fl-324c. The 

and/or QoS labels, the policy servers preferably generate one network 300 also includes one or more repositories, such as 

or more configuration rules. Configuration rules generally repository 326, that is preferably connected to each policy 

instruct intermediate devices how to set-up their various server 322 by a link 328. The repository 326 may be an 

traffic management components or mechanisms. For 5 organization-based directory server, 

example, a configuration rule may contain a Ust of conges- The network 300 may further include one or more 

tion algorithms in descending order of preference. Upon Dynamic Host Configuration Protocol (DHCP) servers, such 

receipt of the configuration rule, an intermediate device ^s server 329, that is also coupled to the pohcy seiver 322 

examines the list and preferably adopts the first congestion ^ither direcUy or mdirecUy^ DHCP, which is defined at 

1 -.u *u * ^ ^ ,n Request for Comments (RFC) 2131, is built upon a client- 

algonthm that it supports. lO ^^^J.^^^del, where DHCP servers allocate IP addresses and 

In the preferred embodiment, the policy servers and ^^^^^^j, network configuration parameters to DHCP clients 

intermediate devices utilize an extension to the Common y^^^^ ^ud stations). Because IP addresses can be a 

Open Policy Service (COPS) protocol to exchange mes- scarce resource in some computer networks, DHCP servers 

sages. More specifically, an intermediate device sends a assign them only for limited periods of time (referred to as 

Query Configuration message to the policy server that i5 ^ lease). Once a lease has expired, the corresponding IP 

contains specific information about itself, such as the num- address may be re-assigned to another host, 

ber and type of interfaces, whether the device is at a Attached to the switches 306-314 and routers 316-318 

boundary of the intermediate domain and/or whether its are a plurality of end stations 330-346 and servers 348-352, 

interfaces are coupled to trusted or un-trusted devices. This which may be file servers, print servers, etc. In particular, 

device -specific information may be loaded in the query 20 four end stations 330-336 are connected to switch 306, one 

message as COPS objects. In response, the policy server end station 338 and one server 348 are connected to switch 

selects a particular set of transactions or rules responsive to 308, two end stations 340 and 342 are connected to switch 

the device-specific information and provides them to the 310, one server 350 is connected to router 318, two end 

intermediate device. Preferably, the transactions and rules stations 344 and 346 are connected to switch 312, and one 

are similarly embedded as COPS objects in response mes- 25 server 352 is connected to switch 314. 

sages. As described above, the intermediate device reviews Software entities (not shown) executmg on the various 

these transactions and rules and implements those mles end stations 330-346 and servers 348-352 typically com- 

which are compatible with its particular traffic management mumcate with each other by exchangmg discrete packets or 

^^^^«««tc rr^^^h^nicTvc fi-ames of data accordmg to predefined protocols, such as the 

components and mechamsms. Transmission Control Protocol/Internet Protocol (TCP/IP), 

BRIEF DESCRIPTION OF THE DRAWINGS the Internet Packet Exchange (IPX) protocol, the AppleTalk 

protocol, the DECNet protocol or NetBIOS Extended User 

The above and further advantages of the invention may be interface (NetBEUI). In this context, a protocol consists of 

better understood by referring to the following description in a set of rules defining how the entities interact with each 

conjunction with the accompanying drawings, in which: other. Data transmission over the network 300 consists of 

FIG. 1, previously discussed, is a block diagram of a prior generating data in a sending process executing on a first end 

art frame; station, passing that data down through the layers of a 

FIG. 2, previously discussed, is a block diagram of a protocol stack where the data are sequentially formatted for 

portion of a prior art Internet Protocol (IP) header; delivery over the Unks as bits. Those firame bits are then 

HG, 3 is a highly schematic, partial diagram of a com- 40 received at the destination station where they are 

outer network' re-assembled and passed up the protocol stack to a receiving 

. . c process. Each layer of the protocol stack typically adds 

FIG. 4 is a highly schematic, partial block diagram of a information (in the form of a header) to the data generated 

policy server m accordance with the present invention; ^^^^^ ^^^^^ ^ ^^^^ descends the stack. At the 

FIG. 5 is a highly schematic, partial block diagram of an destination station, these headers are stripped off one-by-onc 

intermediate device in accordance with the present inven- as the frame propagates up the layers of the stack until it 

tioni arrives at the receiving process. 

FIG. 6 is a preferred traffic template that may be selected Preferably, routers 316-318 are layer 3 intermediate 

by a network administrator; and devices and thus operate at the internetwork layer of the 

FIGS. 7A-7F are block diagrams of data structures asso- so communication protocol slack implemented within the net- 

ciated with the template of FIG. 6. work 300. For example, routers 316-318 preferably include 

an Internet Protocol (IP) software layer, as defined by the 

DETAILED DESCRIPTION OF THE weU-known TCP/IP Reference Model. Routers 316-318 

PREFERRED EMBODIMENT implement network services such as route processing, path 

FIG. 3 is a highly schematic block diagram of a computer 55 determination and path switching functions. Switches 

network 300. The network 300 may be segregated into one 306-314 may be layer 2 intermediate devices and thus 

or more network domains by a network administrator, such operate at the data link layer of the corresponding commu- 

as network domains 302 and 304, as described below. The nication protocol stack. Switches 306-314 provide basic 

network 300 includes a plurality of entities, such as end bridging functions including filtering of data traffic by 

stations and servers, interconnected by a plurality of inter- 60 medium access control (MAQ address, "learning" of a 

mediate devices, such as bridges, switches and routers. In MAC address based upon a source MAC address of a firame 

particular, network 300 includes a plurality of switches and forwarding of the frame based upon a destination MAC 

306-314 and routers 316-318 interconnected by a number address or route information field (RIF). Switches 306-314 

of links 320a to 320/ which may be high-speed point-to- may further provide certain path switching and forwarding 

point or shared links. Each domain 302 and 304, moreover, 65 decision capabilities normally only associated with routers, 

includes at least one policy server 322 that is preferably In the illustrated embodiment, the switches 306-314 and 

connected to one or more intermediate devices, such as routers 316-318 are computers having transmitting and 
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receiving circuitry and components, including network 418. As shown, the device-specific filter entity 416 commu- 

interface cards (NlCs) establishing physical ports, for nicates with both the policy rule generating engine 414 and 

exchanging data firames. The switches 306-314 and routers the communication engine 418, The communication engine 

316-318 further comprise programmable processing 418, moreover, is preferably configured to exchange mes- 

elements, which may contain software programs pertaining 5 sages with the intermediate devices (e.g., switches 306-314 

to the methods described herein. Other computer readable ^ud routers 316-318) of network 300. That is, communica- 

media may also be used to store the program instructions. In j^q^ engine 418 is connected to or includes conventional 

addition, associated with each port or physical network circuitry for transmitting and receiving messages across 

connection is one or more logical connections or interfaces ^^^^^^^j^ ^^^^ ^ 324fl-324c. 

defined by the IP software layer, * • . . <• • 

^ . , j-.j- A server suitable for use as policy server 322 is any 

The terms router or layer 3 mtermediate device as used , ^ . i^rr^ tt • u j t *r 

, . • . J jt_ ji . • . J- * J • Intel/Wmdows NT® or Umx -based platform, 
herein are mtended broadly to cover any mtermediate device 

operating primarily at the internetwork layer, including, ^ ^ P^^ial block diagram of an intermediate 
without limitation, routers as defined by Request for Com- ^^vi^^' ^uch as router 318, in accordance with the preferred 
ments (RFC) 1812 from the Internet Engineering Task Force . . embodiment of the present invenUon. Router 318 preferably 
(IETF), intermediate devices that are only partiaUy compli- "^^1"^^^ a communication engine 510 that is coupled to a 
ant with RFC 1812, intermediate devices that provide addi- ^'^^^ management controller 512. The communication 
tional functionaUty, such as Virtual Local Area Network ^^^^^ configured to exchange messages with the 
(VLAN) support, IEEE 802.1Q support and/or IEEE 802.1D po^^^y server 322. That is, communication engme 510, like 
support, etc. The terms switch and layer 2 intermediate ,0 communication engme 418 at poUcy server 322, is 
device are also intended to broadly cover any intermediate similarly connected to or mcludes conventional arcuitry for 
device operating primarily at the data link layer, including, transmittmg and receiving messages across the network 300. 
without limitation, devices that are fully or partially com- Th« ^rafiSc management controller 512, which mcludes a 
pUant with the IEEE 802.1D standard and intermediate Po^i^y "He decoder 514, is coupled to several components 
devices that provide additional functionality, such as Virtual mechanisms. In particular, traffic management control- 
Local Area Network (VLAN) support. IEEE 802.1Q support ^^r 512 is coupled to a packet/frame classifier 516, a traffic 
and/or IEEE 802.1p support. Asynchronous Transfer Mode conditioner entity 518, a queue selector/mapping entity 520 
(ATM) switches. Frame Relay switches, etc, ^ scheduler 522, The traffic conditioner 518 also 

It should be understood that the network configuration ^^^"^.^^ ^^^^^^ sub-components, mcluding one or more 

300 of HG. 3 is for illustrative purposes only and that the 30 """^^""^ ^""^T^ ^?f' °' "^^'^ ^.o^ ^""^^ 

present invention will operate with other, possibly far more shaper/dropper entities 528. The queue selector/ 

complex, network topologies. It should be further under- "^^PP^^S enUty 520 and scheduler 518 operate on the various 

stood that the repository may be indirectiy connected to the ?^^^f established by router 318 for its ports and/or 

poUcy servers (e.g., through one or more intermediate interfaces^ such as queues 530^-530^ corresponding to an 

devices), 35 "^'^^f^^532. 

As described above, computer networks often include ^ Domains and Selection of High-Level 

intermediate devices fi"om many different vendors or, even if "olicies 

from the same vendor, having different hardware architec- First, the network administrator preferably identifies vari- 
tures or executing different versions of software. ous regions of his or her computer network 300 to which he 
Accordingly, these intermediate devices provide many dif- 40 she wishes to have different, high-level traffic manage- 
ferent features and options. For example, a first switch may °ient polices applied. The identification of such regions may 
provide only 2 priority queues per port, whereas a second depend on any number of factors, such as geographic 
switch may provide 8 priority queues per port. With regard location, business unit (e.g., engineering, marketing or 
to congestion algorithms and techniques, some intermediate administrative), anticipated network demands, etc. The net- 
devices may only support tail dropping, while others may be 45 work administrator preferably defines a separate Quality of 
selectively configured to provide random early detection Service (QoS) or network domain for each region and 
(RED). Thus, it is extremely difficult for a network admin- assigns a primary policy server (e.g., policy server 322) to 
istrator to configure all of the intermediate devices in each QoS domain (e.g., domain 302). Thus, a QoS domain 
accordance with a single, uniform traffic management plan. is basically a logical set of entities and intermediate devices 
As result, network-wide quality of service is generally not 50 defined by the network administrator. As described below, 
available. As described herein, the present invention pro- the primary policy server is responsible for propagating the 
vides a method and apparatus for allowing network admin- high-level traffic management polices to the intermediate 
istrators to apply high-level traffic management policies that devices within its QoS domain. 

attempt to impose such a uniform plan, despite the presence It should be understood that the policy server 322 may, 

of dissimilar intermediate devices in their networks. The 55 but need not, be physically located within its QoS domain, 

traffic management policies, moreover, may be automati- It should be further understood that back-up or standby 

cally propagated to and implemented by the various inter- policy servers may also be assigned to the QoS domains 

mediate devices. should any primary policy server fail. 

FIG. 4 is a highly schematic, partial block diagram of In addition, the boimdaries of the network domains 302, 

policy server 322 in accordance with the preferred embodi- 60 304 may be established so as to only include trusted devices, 

ment of the present invention. The policy server 322 is A "trusted device" is an entity (e.g., an end station or server) 

comprised of several components, including a policy trans- which is considered to correctly classify the packets that it 

lator 410 having one or more storage devices 412a— 412c. sources and to keep its transmission of packets in-profile 

Policy server 322 also includes a policy vahdation tool (i.e., within the bounds of the traffic specifiers of any 

(PVT) 413 and a policy rule generating engine 414 that are 65 applicable service level agreements). A packet is classified 

each in communication with the policy translator 410, a by loading its user_priority field 114, ToS fields 202 and/or 

device-specific filter entity 416 and a communication engine DS field 220 with a particular value or codepoint. Similarly, 
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an "un-trusted device" is an end station or server which is 
not assumed to correctly classify its own packets and/or 
maintain its flow of traflSc within all applicable traffic 
specifiers. Packets from an un-tnisted device must be exam- 
ined and reclassified as necessary. Additionally, the flow 
from un-trusted devices must be policed. In a similar 
manner, the ports of an intermediate device that are coupled 
to one or more un-trusted devices are referred to as "un- 
trusted ports", whereas ports coupled to only trusted devices 
are "trusted ports". 

Once the QoS domains have been defined, the network 
administrator preferably proceeds to select the high-level, 
device-independent traffic management policies that arc to 
be implemented within each domain. First, the network 
administrator selects an overall traffic template that estab- 
lishes the different traffic types that are to be supported 
within the respective QoS domain. In particular, the network 
administrator may select one of several available traffic 
templates. An exemplary traffic template may be the traffic 
type list estabhshed by the IEEE in the 802. Ip standard, 
which defines the following traffic types: best effort, 
background, excellent effort, controlled load, video, voice 
and network control, as described above. Other traffic tem- 
plates include a financial template, a manufacturing template 
and a university or education template. 

FIG. 6 is a highly schematic representation of a financial 
template 610 for use by a network administrator in accor- 
dance with the present invention. As shown, the financial 
template 610 includes a first column 612 listing a plurality 
of available traffic types corresponding to the financial 
template 610, The available traffic types include best effort, 
background, CEO best effort, voice, business applications, 
stock exchange applications, 500 kb/s video conference, 2 
Mb/s video conference and network control. A second 
column 614 identifies a particular differentiated service (DS) 
value corresponding to each traffic type. The DS codepoint 
establishes the overall treatment that is to be assigned to the 
corresponding traffic type within the respective QoS domain 
302. To fit within the first six bits of DS field 220, DS 
codepoints are in the range of 0-63. As described below, the 
DS codepoints may also be used by intermediate devices in 
loading the user__priority and/or ToS fields 114, 202 with 
corresponding values during classification. 

A third column 616 identifies the network users who may 
take advantage of the various traffic types. For example, the 
network administrator may decide that any network user 
may utilize the best effort, background, voice, 500 kb/s 
video, 2 Mb/s video and network control traffic types. 
However, only the chief executive officer (CEO) may take 
advantage of the CEO best effort traffic type and only 
network users from the marketing, administrative, 
executive, financial analysis and financial planning depart- 
ments may utilize the business applications traffic type. 
Similarly, only network users from the financial analysis, 
financial planning and trading departments may use the 
stock exchange applications traffic type. A fourth column 
618 identifies the application programs corresponding to 
each traffic type. For example, available business applica- 
tions may include a spreadsheet application, a word proces- 
sor application, or any of the well-known and commercially 
available business applications from SAP AG of Walldorf, 
German or PeopleSoft, Inc. of Pleasanton, Calif. A stock 
exchange application may be TIB from TIBCO Inc. of Palo 
Alto, Calif. The identification of network users in column 
616 and the application programs in column 618 are pref- 
erably entered by the network administrator. The network 
administrator may rely on default DS codepoints in column 
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614 or may change these values as desired. The traffic types 
and DS codepoints for a given template arc preferably 
derived from empirical studies and analysis of the computer 
network operations and usages of such industries and orga- 
nizations. 

In order to select the desired template and enter the 
requested information, the network administrator may inter- 
act with various windows of a graphical user interface 
(GUI). These windows, for example, may present fields, 
such as the entries for columns 616 and 618, having pull- 
down menus that request information from the network 
administrator. The information may be entered by the net- 
work administrator using a mouse or keyboard in a conven- 
tional manner. The user interface, moreover, is preferably 
similar in operation to the Cisco Works Windows interface 
(for configuring router interfaces) or the VlanDirector inter- 
face of the Cisco Works for Switched Internetworks (CWSI) 
interface (for configuring VLANs), both from Cisco 
Systems, Inc. 

It should be understood that other means of associating 
traffic types to users, applications and DS codepoints, 
besides traffic templates, may be employed. It should also be 
understood that network administrators may select different 
traffic templates or adjust their parameters for different times 
of day or for emergency situations. 

Next, the network administrator defines any location- 
specific policies. For example, the network administrator 
may specify that intermediate devices located at the border 
of the QoS domain should only accept traffic that belongs to 
a specific group, such a company employees, department 
members, etc. Any traffic which does not belong to the group 
should be dropped. The network administrator may also 
define one or more lists of global parameters that are to be 
utilized throughout the QoS domain. An example of a global 
parameter list is a prioritized list of queue scheduhng 
algorithms from first choice to last choice, such as WFQ, 
WRR and Priority Queuing (PQ). Other examples of global 
parameter lists include congestion algorithms (e.g., RED 
over tail dropping), enabling muhi-link Point-to-Point Pro- 
tocol (PPP) fragmentation, if available, and enabling Virtual 
Circuit (VC) merging, if available. 

Associated with the template 610 are one or more data 
structures and, as information is entered into the template 
610, these data structures are preferably updated accord- 
ingly. As described below, these data structures are used to 
generate the traffic management rules implemented by the 
intermediate devices. FIGS. 7A-7E are block diagrams of 
exemplary data structures associated with template 610. In 
particular, FIG. 7A is a network user table 710 that maps 
users identified in column 616 of template 610 with actual 
user names and/or IP addresses and masks. User table 710 
preferably includes a user column 712, a name column 714, 
an IP addrcss column 716, an IP mask column 718 and a 
plurality of rows such that the intersection of a column and 
row defines a table entry. As information is entered in 
column 616 of template 610, corresponding entries are made 
in the user column 712 of table 710. As described below, 
information for columns 714, 716 and 718 is subsequently 
added by the policy server 322. FIG. 7B is an application 
table 730 that maps the applications programs entered on the 
financial template 610 to their network protocol, such as the 
Transmission Control Protocol (TCP) or User Datagram 
Protocol (UDP) port numbers. In particular, application 
table 730 preferably includes a first column 732 listing the 
application programs identified in the selected template 610 
and a second column 734 that identifies both the transport 
protocol and the port number for each corresponding appli- 
cation program. 
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FIG. 7C is a classifier table 740 that maps DS codepoints, 
including those specified by the network administrator in the 
selected template 610, with corresponding values for use in 
classifying or shaping traffic within the corresponding QoS 
domain 302, as described herein. In particular, each avail- 
able DS codepoiot (0-63), which is loaded in a first colmnn 
742, is preferably mapped to a DS mark down value 
contained in a second column 744, a User Priority value 
contained in a third column 746 and a Type of Service (ToS) 
value contained in a fourth column 748. Preferably, table 
740 is preconfigured with a set of default values correspond- 
ing to the selected template 610. The network administrator 
may, however, access table 740 while establishing the high 
level policies and modify these values. 

FIGS. 7D-E are exemplary queue/threshold assignment 
tables that map DS codepoints to queues and thresholds 
depending on the number of queues and thresholds that are 
available at a given interface. For example, FIG, 7D is a first 
queue/threshold assignment table 760 for an interface sup- 
porting two queues and two thresholds per queue. As shown, 
table 760 includes a column 762, 764 for each queue and a 
row 766, 768 for each threshold. At the intersection of each 
column and row is cell 170a-d that contains the set of DS 
codepoints for the corresponding queue/threshold combina- 
tion. For example, cell 770fl identifies the set of DS code- 
points (e.g., 0, 4, 8, etc.) to be assigned queue 1 and 
threshold 1. Similarly, cell 770d identifies the set of DS 
codepoints (e.g., 3, 7, 11, 62, 63, etc.) to be assigned queue 
2 and threshold 2. FIG. 7E is a second queue/threshold 
assignment table 774 for an interface supporting 2 queues 
and 4 thresholds. Accordingly, table 774 includes two col- 
umns 776, 778 (one for each queue) and four rows 780-783 
(one for each threshold) whose intersections define a plu- 
rality of cells 7H4a-h. The cells 7S4a~-h contain the set of DS 
codepoints for the corresponding queue/threshold combina- 
tion. 

FIG. 7F illustrates a third queue/threshold assigmnent 
table 788 for interfaces supporting 5 queues and 2 thresh- 
olds. Thus, table 788 includes 5 columns 790-794 and 2 
rows 795, 796 whose intersections define a plurality of cells 
79Sa-j. As described above, each cell 798fl-y includes a set 
of DS codepoints for the corresponding queue/threshold 
combination. For example, cell 79Sa includes DS code- 
points 0, 10, etc., while cell 798g includes DS codepoints 6, 
19, 60, etc. 

It should be understood that a queue/threshold assignment 
is preferably generated for each number of queue/threshold 
combinations supported by the interfaces in the network. 

It should be further understood that tables 760, 774 and 
788 may only assign a subset of DS* codepoints to queues 
and thresholds, rather than all DS codepoints. For example, 
DS codepoints may be segregated into standardized and 
private classes or codepoints. Standardized codepoints are 
assigned particular per hop behaviors by the IE7T such as 
expedited or assured forwarding. Private codepoints may be 
associated with any treatment on an implementation-by- 
implementation basis. The present invention preferably 
maintains the associated behaviors of any standardized 
codepoints. 

Generation of Policy Rules Based on the Selected High- 
Level Policies 

Referring to FIG. 4, these high-level policies, including 
the financial template 610 (FIG. 6), data structures 710, 730, 
740, 760. 774 and 788 (FIGS. 7A-F) and location-specific 
policies, if any, are then provided to the policy server 322. 
In particular, the information is received at the policy 
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translator component 410, as shown by arrow 420. Policy 
translator 410 examines the high-level policies and corre- 
sponding data structures and may perform certain initial 
processing. For example, to the extent the user table 710 fists 

5 individual or group network users by title or department, the 
policy translator 410 may identify the actual users and 
obtain their IP addresses and/or corresponding subnet 
masks. For example, by accessing the repository 326 and/or 
other information resources, such as DHCP server 329, the 
policy translator 410 may enter additional information in 
table 710. In particular, the policy translator 410 may query 
the repository 326 or DHCP server 329 to obtain the CEO's 
name, IP address and IP mask. This information may then be 
inserted in the corresponding entries of user table 710. 

J J Similar information, where appropriate, may be obtained for 
groups, such as the marketing, administrative and executive 
departments, from repository 326 or DHCP server 329, and 
entered into user table 710. The policy translator 410 may 
employ a conventional database query-response application 
such as SQL and the Light weight Directory Access Protocol 
(LDAP) to communicate with the repository 326 and DHCP 
server 329. Alternatively, the policy translator 410 may be 
pre-configiued with such information. 

The information for column 732 of the application table 

25 730 may also be obtained and inserted by the policy trans- 
lator 410. In particular, policy translator 410 may include a 
database that correlates application programs to transport 
protocol and port number. Many applications, such as the 
hyper text transport protocol (HTTP), are assigned specific, 

30 fixed TCP/UDP port numbers, such as port 80, in accordance 
with Request for Comments (RFC) 1700. This information 
may be stored by the policy translator 410 in a conventional 
maimer. Although RFC 1700 provides fixed port numbers 
for hundreds of applications, there are still many applica- 

35 tions that do not have predefined, fixed port numbers. The 
port numbers utilized by these application are typically 
selected dynamically by the instances of the application 
program executing at the sending and receiving devices at 
the time the respective communication session is estab- 

40 lished. 

To identify these dynamically selected port numbers, the 
intermediate devices may perform a stateful inspection of 
received packets for any given communication session. This 
stateful inspection will reveal the port numbers selected by 

45 the corresponding entities. A suitable method for performing 
such stateful inspections is the Context Based Access Con- 
trol feature of the Internetwork Operating System (I OS) 
from Cisco Systems, Inc. For some appUcation programs, 
corresponding software modules may exist for identifying 

50 the selected port numbers for any given session of that 
application program. For example, software module 
@h245. voice. inspect is used to identify the port numbers 
selected by instances of H323.voice appUcations. Poficy 
translator 410 may be configured with the identity of these 

55 modules for insertion in the appropriate entry of application 
table 710. 

It should be understood that these data structures (e.g., 
tables 710, 730, 740, 760, 774 and 788) may be stored by 
policy translator 410 at its storage devices 412a-412c. It 
60 should be further understood that the policy generator 410 
may also generate and store additional data structures in 
response to the high-level poUcies selected by the network 
administrator. 

As tables 710, 730, 740, 760, 774 and 788 are loaded 
65 and/or up-dated, the poficy rule generating engine 414 
accesses this information and creates one or more rules that 
can be transmitted to the intermediate devices within the 
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respective QoS domain 302. These rules, moreover, which 
may include one or more access control lists, are in a format 
that is both readable and executable by the intermediate 
devices, as described below. 

First, the policy rule generating engine 414 creates a set 
of classification rules. Classification rules are generally 
utilized by intermediate devices to assign a given treatment 
to network trafiSc based on certain criteria, such as source or 
destination address, protocol, port number, application 
program, etc. In the preferred embodiment, classification 
rules, which include one or more objects, are applied at 
specific locations (e.g., an interface or group of interfaces 
coupled to un-trusted devices) or at intermediate devices 
located at the boundary of the QoS domain 302. Location- 
specific classification rules preferably have the following 
format: 

<location><direction> <acl > <rmo> <CIassificatio n_DecisioiU- 
Ruto 

where, the "location" object identifies a particular interface, 
interface type or role as described below, the "direction" 
object refers to whether the rule is to be apphed to packets 
at the input, output or both portions of the interface(s), the 
"access control list" (acl) object contains a Ust of criteria 
statements to be applied to the packets and the "rule man- 
agement object" (rmo) instructs the intermediate device how 
to respond if conflicting actions are returned and the 
"Classification_Decision__Rule" object is the actual rule or 
rules being implemented to packets matching the acl object. 
Although the rmo preferably instructs the intermediate 
device to select the best match, other tie-breaking solutions 
may be presented. The second format of a classification rule, 
which is used with intermediate devices located at the 
boundary of the QoS domain 302, appears as follows. 

<acl><nno > <Classification_Decision_Rule> 

In addition, the acl object may have one of two formats. 

(1) <destination IP address or destination IP raaskxsource 
IP address or source IP maskxprotocolxsource and/or 
destination port numbers> or 

(2) <destination or source MAC address> 

In the preferred embodiment, classification rules are used 
for one of three primary purposes: (1) assigning a DS 
codepoint to packets, (2) assigning a QoS label to packets 
while they are processed within an intermediate device or 

(3) instructing an intermediate device to shape, mark and/or 
drop out-of-profile trafiSc. For example, a classification rule 
may be used at the border intermediate devices instructing 
them to drop packets with a given source IP address or IP 
mask. A classification rule may also be used to assign a given 
DS codepoint to all traffic associated with a given IP mask 
(e.g., all traflic from the marketing department) or all traffic 
associated with a given port (e.g., port 23 for Telnet). 

As described above, only sixty-four DS codepoints are 
supported by the DS field 220. To extend the concept of 
packet-specific differentiated services beyond sixty-four 
options, the present invention also utilizes Quality of Ser- 
vice (QoS) labels. A QoS label is a name string of any length 
(e.g., an integer, an alphanumeric string, etc) that may be 
associated with a packet while it remains internal to the 
intermediate device. Classification rules may also be used to 
assign QoS labels to packets based on their source or 
destination address, protocol, application, etc. As described 
below, intermediate devices maintain a mapping of QoS 
labels to traffic types and to the corresponding action to be 
taken or service to be provided. 
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Next, the policy rule generating engine 414 creates a set 
of behavioral rules, which are utilized to instruct interme- 
diate devices how to treat data traffic assigned a particular 
DS codepoint and/or QoS label by the classification rules. 
5 Behavioral rules also include one or more objects and are 
preferably applied at all compliant intermediate devices 
within the QoS domain 302. Behavioral rules may be 
location-specific or location-independent. The preferred for- 
mat of a location-specific behavioral rule is as follows. 

10 

<localion><dircction><labeI_Test><Bchavioral_Rulc_Decision> 

where the "label_Test" object may be <dsc_Test> (e.g., DS 
codepoint«N, where N is some number, such as "32") or 
<QoS„Label_Test> (e.g., QoS Label«N). The preferred 
format of a location-independent behavioral rule is as fol- 
lows. 


<label_Test><Behavioral_Rule_Decision> 

20 

By applying the label_Test to each packet, the interme- 
diate device determines whether the corresponding 
Behavioral_Rule_Decision should be applied. The 
Behavioral_Rule_Decision object preferably implements 

25 one or more of five possible decisions: select queue, select 
queue threshold, set the User_Priorily field 114, set the IPP 
sub-field 210 or shape, mark and/or drop packets satisfying 
the label_Test object. For example, a behavioral rule may 
instruct the intermediate devices to set to "6" both the 

30 User_Priority field 114 and the IPP sub-field 210 of all 
fi-ames or packets whose DS codepoint is "61". Similarly, 
another behavioral mle may instruct intermediate devices to 
place all messages whose DS codepoint is "32" (e.g., data 
frames from a stock exchange application) in a high priority 

35 queue. Behavioral rules may similarly specify a particular 
treatment based on the QoS label, user priority or type of 
service of a packet or frame, such as fast or reliable service. 
In response, an intermediate device may select a particular 
transmission link. Since behavioral rules lack an rmo object, 

40 intermediate devices apply all behavioral rules they support, 
not just the first one. If multiple behavioral rules specify 
contradictory actions, the last one preferably takes prece- 
dence. 

To implement traffic management policies that are inde- 
45 pendent of DS codepoints and/or QoS labels, the policy rule 
generating engine 414 preferably creates a plurality of 
configuration rules. In general, configuration rules instruct 
intermediate devices how to set-up their various traffic 
management components or mechanisms. Configuration 
50 rules also have a location-specific and location-independent 
format which are preferably as follows. 

<location><direction><Co nfiguration_Rule_Deds ion> 

<Configuration_Rule_Decision> 

55 The "Configuration_Rule Jecision" object may be used 
to specify certain global parameters or algorithm param- 
eters. For example, the Configuration_Rule_Decision 
object of a given configuration rule may contain a list of 
congestion algorithms in descending order of preference, 

60 such as WFQ, WRR, PQ and none. In addition, if an 
intermediate device uses tail drop and supports four different 
drop thresholds per queue, a configuration mle may set the 
four thresholds (e.g., at 50%, 80%, 95% and 100% of the 
buffer limit) and assign a name to each threshold. Similarly, 

65 if an intermediate device supports WRED, a configuration 
rule may be used to set the minimum threshold, maximum 
threshold and probability constant for each weight. Also, for 
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WRR, a configuration rule may assign the weights to the mines that router 318 has five queues 530fl-530e per inter- 
various queues. face 532. Additionally, trafiSc management controller 512 

The rule generating engine 414 may also combine several may detennine that each queue 530a-530e may support 

related rules into a transaction. More specifically, rules that either RED or tail dropping and supports two sellable 

are meaningful only if applied simultaneously and which 5 thresholdsper queue. The traffic management conU-oller 512 

may cause transient misconfigurations if implemented one at f^^her identify the roles assigned to one or more of its 

a time, are combined into a transaction. For example, a interfaces. r • 

network administrator may want to log as weU as drop all ^ol^^ preferably specify the type or nature of an interface 

attempts to access a subnetwork or LAN by a known hacker. sub-interface. For example, an mterface may be trusted or 

n ' , I ♦u * 1 -A e un-trusted. It may configured to perform policing and shap- 

Rather than issue a separate rule that only provides for lO ^/^^ ^ Lbscribing netw^k. It may be a 

loggmg and a subsequent rule for droppmg, which might backbone interface and thus multiplex large volumes of 

result m transitory access by the hacker, these two rules (log ^^^^ ^^e backbone network or it may be a QoS border 

and drop) are preferably combined into a single transaction. interface. An interface may also have more than one role. 

A "transaction start" object is preferably used to indicate the particular role or roles of an interface are preferably 

start of a set of mles forming a transaction and a "transaction 15 assigned by a network administrator utilizing a management 

end" object indicates the end. As described below, the mles protocol, such as Simple Network Management Protocol 

and transactions are accessible by the device -specific filter (SNMP) or CiscoWorks from Cisco Systems, Inc., during 

entity 416 which collects relevant rules for transmission to configuration of the interface. A corresponding flag, label or 

the intermediate devices. name may be maintained by the device to identify the 

To generate the particular rules for a given QoS domain, 20 various roles of its interfaces. For router 318, the interface 

the policy rule generating engine 414 preferably performs a coupled to domain 304 may be assigned the role of policing 

conventional algorithmic transformation on the correspond- and shaping traffic fi-om subscribing domain 304 in accor- 

ing data structures (e.g., tables 710, 730, 740, 760 and 770). dance with one or more traffic specifiers. 

This algorithmic transformation converts the information The assignment of roles facilitates the creation and imple- 

from the data structures into the necessary access control list 25 mentation of network policies. In particular, global policies 

objects and classification, behavioral and configuration rule may be defined that apply to all interfaces regardless of their 

objects of the corresponding rules. Such algorithmic trans- particular roles. Local policies apply to the role at one 

formations are well-known to those skilled in the art. The specific interface. In other words, policies may be assigned 

objects comprising the various rules, including the rule to roles and roles may be assigned to the various interfaces 

objects themselves, may be defined using Abstract Syntax 30 in the network. Thus, by simply changing the role at a given 

Notation One (ASN.l) which is well-known to those skilled interface, a network administrator ensures that the appro- 

in the art. priate network policies are automatically propagated to and 

The policy translator 410 also interfaces with the policy implemented by that interface. Each role, moreover, may 

validation tool (PVT) 413 to identify any conflicting poli- have a corresponding precedence to resolve any conflicts 

cies. That is, the PVT 413 examines the high-level policies 35 that might arise at an interface assigned more than one role, 

and performs a conflict check. In particular, the PVT 413 All of this information may be transmitted by the traffic 

determines whether the policies ascribe confficting treat- management controUer 512 to the communication engine 

ments to the same traffic. For example, two polices may caU 510 along with an instruction to send to the information to 

for different shaping or marking to be applied to the same the policy server 322. In response, the communication 

traffic stream. Another policy may be incomplete by failing 40 engine 510 preferably formulates a Configuration Request 

to specify a requisite condition. All confficts detected by the message that includes the information received from the 

PVT 413 are reported to the policy translator 410. The PVT traffic management controller 512 as a series of objects. The 

413 may also determine whether sufficient network Configuration Request message is then transmitted by the 

resources exist to implement the policies. For example, a communication engine 510 to the policy server 322. 

policy may require at least one network path having 3 or 45 At the policy server 322, the Configuration Request 

more queues at each intermediate device along the path. If message is received at the corresponding communication 

no such path exists, the PVT 413 preferably reports this engine 418 and handed to the device-specific filter enrity 

condition to the policy translator 410. 416. The device-specific filter entity 416 examines the 

Propagation of the Policy Rules to Intermediate Devices Configuration Request to determine what types of network 

In operation, intermediate devices within a QoS domain 50 resources and services are available at router 318 and what 

will request traffic management information from the local roles if any are associated with its interfaces. In particular, 

policy server. This information will then be utilized by the the device-specific filter entity 416 determines that router 

intermediate devices in setting their resources and in making 318 supports both RED and tail dropping, has five queues 

traffic management decisions. In the preferred embodiment, with two settable thresholds per queue and an interface 

the policy server and intermediate devices utilize an exten- 55 whose role is to police and shape traffic from a subscribing 

sion to the Common Open Policy Service (COPS) client- network. Based on this determination, the device-specific 

server communication protocol. In particular, the policy filter entity 416 obtains a particular set of transactions and/or 

server and the intermediate devices preferably utilize the mles from the pohcy rule generating engine 414 that cor- 

COPS extension described in COPS Usage for Differenti- responds to the network services and resources avaflable at 

ated Services, an Internet Draft Document, dated August 60 router 318. For example, the device-specific filter entity 416 

1998, from the Network Working Group of the IETF, which may obtain one or more classification rules instructing router 

is hereby incorporated by reference in its entirety. 318 to classify packets from a given source (e.g., domain 

More specifically, referring to FIGS. 4 and 5, upon 304) with a given DS codepoint and/or QoS label. Rules for 

initializationof router 318, the traffic management controller policing and shaping traffic from domain 304 may also be 

512 polls the various components and mechanisms to deter- 65 obtained. 

mine what network resources and services router 318 has to Additionally, the device-specific filter entity 416 may 

offer. For example, traffic management controller 512 deter- obtain one or more behavioral mles that instmct router 318 
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to map packets with various DS codepoints to specific 
queues and thresholds in accordance with the information 
contained in table 788 (FIG. 7F). More specifically, a first 
behavioral rule may provide for mapping packets with a DS 
codepoint of 0, 10, etc. (e.g., DS codepoints corresponding 
to cell 798fl) to queue 1 (e.g., queue 530a) and the lower 
threshold. Another behavioral rule may map packets with a 
DS codepoint of 6, 19, 60, etc. (e.g., DS codepoints corre- 
sponding to cell 798g) to queue 2 (e.g., queue 5306) and the 
second threshold and so on. Thus, a set of behavioral rules 
are obtained that will allow router 318 to map various 
packets based on their DS codepoints to queues 530a-530e 
and corresponding thresholds. 

Filter entity 416 may also obtain one or more configura- 
tion rules. For example, filter entity 416 may obtain a 
configuration rule for use in setting the scheduler 522. In 
particular, a configuration rule may provide a list of sched- 
uling algorithms in a preferred order (e.g., WFQ, WRR and 
Priority Queuing). Another configuration rule may provide 
that Virtual Circuit merging should be applied where avail- 
able. Filter entity 416 may access the policy rules via a 
virtual information store, such as the Policy Information 
Base (PIB) specified in the draft COPS Usage for Differen- 
tiated Services document. 

Once the device-specific filter entity 416 has obtained a 
set of transactions or rules for router 318, it provides them 
to the communication engine 418 which, in turn, loads them 
into one or more Decision Messages. These Decision Mes- 
sages are then transmitted by communication engine 418 to 
router 318. Communication engine 510 at router 318 
receives the Decision Messages, extracts the rules contained 
therein and provides them to the traflSc management con- 
troller 512 where they may be decoded by policy rule 
decoder 541. TrafBc management controller 512 may also 
build one or more data structures (such as tables) to store the 
mappings contained in any received behavioral rules. 

It should be understood that intermediate devices learn of 
the identity of the policy server 322 through any conven- 
tional means, such as manual configuration or a device 
configuration protocol. 

Implementation of the Policy Rules at Specific Interme- 
diate Devices 

First, traflSc management controller 512 proceeds to con- 
figure its components and mechanisms in accordance with 
the instructions contained in the classification rules. For 
example, to the extent router 318 supports Virtual Circuit 
merging, this featiu-e is enabled. Similarly, to the extent 
scheduler 522 can implement WRR and Priority Queuing, 
trafiSc management controller 512 configures it to use WRR. 
As packets are received at router 318, they are examined by 
the packet/frame classifier 516 which reports the contents of 
the packet's User_Priority field 114, IPP sub-field 210 
and/or DS field 220 to the traffic management controller 512. 
Packet/frame classifier 516 may also supply other packet 
header information to the traffic management controller, 
such as source IP address, port, protocol, etc. In response, 
the traffic management controller 512 relies on the received 
behavioral rules to determine in which queue 530fl-530e the 
corresponding packet should be placed for forwarding and to 
instruct the queue selector/mapping entity 520 accordingly. 
Similarly, router 318 relies on the behavioral rules to deter- 
mine which packets to mark down and/or drop. 

Furthermore, to the extent router 318 policies traffic 
received from subscribing domain 304, additional configu- 
ration rules may be provided to router 318 for setting its 
traffic conditioner entity 518. For example, one or more 
configuration rules may instruct router 318 to activate its 


meter entity 524 so as to monitor the traffic arriving from 
domain 304. If out-of -profile traffic is to be marked through 
marker entity 526, classification rules may be provided for 
re-setting the DS codepoints of traffic that is out-of-profile 
based on the information contained in table 740. 
Alternatively, if out-of-profile traffic is to be shaped or 
dropped, other configuration rules may instruct the associ- 
ated traffic management controller 512 to set the shaper/ 
dropper entity 528 accordingly. 

This process is similarly repeated at each of the interme- 
diate devices within the QoS domain 302 that arc compliant 
with the present invention. Depending on the particular 
network resources and services available at each intermedi- 
ate device, a different set of rules will be selected by the 
device-specific filter entity 416. For example, switch 306 
may similarly send a Configuration Request message to 
policy server 322 and receive a Decision Message. 
Furthermore, based on the information contained in the 
Configuration Request message from switch 306, including 
the fact that switch 306 is coupled to one or more un-trusted 
devices, such as end stations 332-336, the device-specific 
filter entity 416 may obtain one or more classification rules 
for classifying traffic received from these un-trusted devices. 
However, since switch 306 may not operate at the network 
layer, filter entity 416 may obtain classification rules for 
setting the User_Priority field 114 of packets or frames 
received on ports coupled to devices 332-336, depending on 
various parameters of the packets or frames, such as port 
number, protocol type, etc. Filter entity 416 may also obtain 
behavioral rules instructing switch 306 how to handle pack- 
ets based on the user priority value rather than DS codepoint, 
since switch 306 may not be DS-compliant. Alternatively, 
policy server 322 may provide one or more classification 
rules that map User Priority values to DS codepoints so that 
switch 306 may apply one or more behavioral rules that are 
dependent on DS codepoints to packets that have a User 
Priority value. 

It shotild also be understood that less than all of the 
intermediate devices within a given network may be con- 
figured to implement the present invention, although in the 
4Q preferred embodiment, all of the intermediate devices will 
be so configured. 

The foregoing description has been directed to specific 
embodiments of this invention. It will be apparent, however, 
that other variations and modifications may be made to the 
described embodiments, with the attainment of some or all 
of their advantages. For example, other client-server com- 
munications protocols, besides COPS, may be utilized by 
the policy server and intermediate devices. In addition, the 
present invention may also be utilized with other network 
layer protocols, such as IPv6, whose addresses are 128 bits 
long. The present invention may also be used to classify 
other fields of data messages, such as the User Priority field 
of the Inter-Switch Link (ISL) mechanism from Cisco 
Systems, Inc. Therefore, it is the object of the appended 
claims to cover all such variations and modifications as 
come within the true spirit and scope of the invention. 
What is claimed is; 

1. A method for implementing high-level, device- 
independent traffic management policies within a computer 
network having multiple, dissimilar intermediate network 
devices, the method comprising the steps of: 
selecting one or more high-level policies; 
translating the one or more high-level policies into a 

plurality of executable rules; 
receiving a request for traffic management policies from 
an intermediate device supporting a set of network 
services; 
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selecting, in response to the request, one or more rules that 
are compatible with the network services supported by 
the intermediate device; 

forwarding the selected one or more rules to the interme- 
diate device; and 

utilizing the one or more rules to configure the set of 
network services at the intermediate device to realize 
the selected high-level policies. 

2. The method of claim 1 wherein the rules formulated by 
the step of translating include at least one of classification, 
behavioral and configuration rules. 

3. The method of claim 2 wherein the step of selecting 
further includes the step of selecting a predefined trafiSc 
template and loading the selected template with user and 
application information. 

4. The method of claim 3 further comprising the step of 
up-dating one or more data structures associated with the 
selected template as user and application information is 
inserted therein. 

5. The method of claim 4 wherein at least one classifica- 
tion rule includes an access control list object, a rule 
management object and a classification decision rule object. 

6. The method of claim 5 wherein the at least one 
classification rule further includes a location object and a 
direction object. 

7. The method of claim 6 wherein at least one behavioral 
rule includes a label test object and a behavioral rule object. 

8. The method of claim 7 wherein the at least one 
behavioral rule further includes a location object and a 
direction object. 

9. The method of claim 8 wherein at least one configu- 
ration rule includes a configuration rule object. 

10. The method of claim 9 wherein the at least one 
configuration rule further includes a location object and a 
direction object. 

11. The method of claim 10 wherein the step of translating 
includes the step of performing an algorithmic transforma- 
tion on the one or more data structures to obtain the 
corresponding classification, behavioral and configuration 
rules. 

12. A policy server for use in implementing high-level, 
device-independent traflBc management policies within a 
computer network having multiple, dissimilar intermediate 
network devices and one or more information resources, the 
policy server comprising: 
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means for receiving the high-level traffic management 
policies including one or more corresponding data 
structures; 

a policy translator that is configured to access the one or 
more information resources for inserting information in 
the data structures; 

a policy rule generating engine coupled to the policy 
generator and configured to translate the data structures 
into one or more executable traffic management rules; 

a device-specific filter entity coupled to the policy rule 
generating engine and configured to select a subset of 
the one or more traffic management rules in response to 
a request from a respective intermediate network 
device having particular traffic management resources 
and services; and 

and a commimication engine coupled to the device- 
specific filter entity for exchanging requests from inter- 
mediate network devices and selected subsets of the 
one or more traffic management rules. 

13. The policy server of claim 12 wherein the one or more 
corresponding data structures include a user table that maps 
individual network users identified in the high-level polices 
to network addresses and maps network groups to network 
masks. 

14. The policy server of claim 13 wherein the one or more 
corresponding data structures further include an application 
table that maps application programs identified in the high- 
level policies to network protocol and port number. 

15. The policy server of claim 14 wherein the high-level 
traffic management policies are represented by a selected 
trafSc template that maps each of a plurality of traffic types 
defined by the selected traffic template with at least one of 
a differentiated service (DS) codepoint, a network user and 
an application program. 

16. The policy server of claim 15 wherein the one or more 
corresponding data structures further include a queue assign- 
ment table that maps DS codepoints to queue numbers. 

17. The policy server of claim 16 wherein the one or more 
corresponding data structures further include a queue thresh- 
old table that maps DS codepoints to queue thresholds. 

18. The policy server of claim 17 wherein the one or more 
corresponding data structures further include a priority table 
that maps DS codepoints to DS mark down values, user 
priority values and type of service values. 

4> >t^ * K * 
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